196 research outputs found
Automated Verification of Design Patterns with LePUS3
Specification and [visual] modelling languages are expected to combine strong abstraction mechanisms with rigour, scalability, and parsimony. LePUS3 is a visual, object-oriented design description language axiomatized in a decidable subset of the first-order predicate logic. We demonstrate how LePUS3 is used to formally specify a structural design pattern and prove (âverifyâ) whether any JavaTM 1.4 program satisfies that specification. We also show how LePUS3 specifications (charts) are composed and how they are verified fully automatically in the Two-Tier Programming Toolkit
On the Definition of Architecture, Design and Implementation
The terms architecture, design, and implementation are
typically used informally in partitioning software specifications
into three coarse strata of abstraction. But these
strata are not well-defined in either research or practice
and often overlap causing confusion and needless discussion.
To remedy this problem we formally define two criteria:
the Intension and the Locality Criteria, and show that
the intuitive discrimination between the three terms architecture,
design, and implementation is qualitative and not
merely quantitative. We demonstrate that architectural
styles are intensional and non-local; that design patterns
are intensional and local; and that implementations are
extensional and loca
The Architecture of Complexity Revisited: Design Primitives for Ultra-Large-Scale Systems
As software-intensive systems continue to grow in scale and complexity the techniques that we have used to design and analyze them in the past no longer suffice. In this paper we look at examples of existing ultra-large-scale systemsâsystems of enormous size and complexity. We examine instances of such systems that have arisen spontaneously in nature and those that have been human-constructed. We distill from these example systems the design primitives that underlie them. We capture these design primitives as a set of tacticsâ fundamental architectural building-blocksâand argue that to efficiently build and analyze such systems in the future we should strongly consider employing such building-blocks
A manifesto for energy-aware software
According to recent estimates, computing and communications could account for 20% of energy usage globally by 2025.1 This trend shows no sign of slowing. The annual growth in power consumption of Internet-connected devices is 20%. Data centers alone are now accounting for more than 3% of global emissions. Even if you are not worried about this trend on the mega scale, you are likely concerned with the power consumption of the devices in your pocket, on your wrist, and in your ears. Software, hardware, and network attributes all contribute to power usage, but little attention has been given to this topic by the information and communications technology (ICT) community
Demystifying Big Data Adoption: Beyond IT Fashion and Relative Advantage
There is a paradox in big data adoption: a peak of hype and simultaneously an unexpectedly low deployment rate. The present multiple case study research develops a Big Data Adoption (Big2) model that helps to explain this paradox and sheds light on the âwhetherâ, âwhyâ, and âhowâ questions regarding big data adoption. The Big2 model extends beyond the existing Relative Advantage and IT Fashion theories to include organizational, environmental, social variables as well as new psychological factors that are unique to big data adoption. Our analysis reveals that the outcome of big data adoption is indeterministic, which defies the implicit assumption of most simplistic ârational-calculusâ models of innovation adoption: Relative Advantage is a necessary but not sufficient condition for big data adoption. Most importantly, our study uncovered a âDeployment Gapâ and a âLimbo Stageâ where companies continuously experiment for a long time and do not proceed to deployment despite the intent to adopt big data. As a result there are four big data adoption categories: Not adopting, Experimented but Not Adopting, Not Yet Deployed, Deployed. Our Big2 model contributes to provide a Paradigm Shift and Complexity Tolerance perspective to understand the âwhyâ in each of the 4 adoption categories. This study further identifies 9 complexity tolerance strategies to help narrow the Deployment Gap but also shows that big data is not for everyone
Immutable Infrastructure Calls for Immutable Architecture
With the advent of cloud computing and the concept of immutable infrastructure, the scaling and deployment of applications has become significantly easier. This increases the possibility of âconfiguration driftâ as an operations team manages this cluster of machines, both virtual and actual. In this paper we propose a revised view on configuration and architecture. We propose that software deployed on a public or private cloud should, to the furthest possible extent, be immutable and source controlled. This reduces configuration drift and ensures no configuration problems in production as a result of updates or changes. We will show an example of a software project deployed on Amazon Web Services with an immutable Jenkins setup which manages updating the whole cluster and is self-regenerating. We will also discuss how this lends itself naturally to interoperability between clouds, because of the infrastructure-agnostic nature of this approach
- âŠ